1. Technical Field
The present invention relates to the field of data processing, and particularly to the field of integrating a commercial off the shelf (COTS) software application into an existing information technology (IT) infrastructure.
2. Related Art
Many users of IT infrastructures can no longer afford to write a new business application each time their business changes. They prefer to buy a Commercial Off-The-Shelf (COTS) package and then integrate it with their existing systems.
According to the current state of the art, integration projects will typically make use of integration software and tooling. The integration team analyses each system in turn to determine the structure and content of the messages that need to be passed in and out of it in order to make the system perform certain operations. They then use the integration tooling and runtime to create components that route and transform messages, events and requests that flow between the systems at appropriate times to form the combined “solution”.
Increasingly, the cost of integrating systems is becoming greater than the cost of the software packages themselves. There are a number of reasons for this.
The systems being integrated (new and old) belong to different areas of ownership within the organization. This means inter-organizational teams need to cooperate since both the background information for the project and the ownership of design artifacts is distributed.
Pre-existing/COTS-based systems are typically not that well understood and often the only way to discover how they really work is to run them. This means new knowledge and requirements relating to the integration code around these systems can be discovered very late in the development cycle. This can lead to significant levels of rework. Most integration tooling operates at a very detailed, low-level of analysis.
There is no single set of tooling that spans the entire integration solution and so there is always an issue of keeping multiple copies of the data in different tools synched up.
All-in-all this is time-consuming, error prone and there is no “big-picture” view enabling high-level reasoning about the end-to-end solution. The high cost and unpredictable nature of integration projects is a concern to the Services business.
One area in which such integration has been explored in the prior art involves the well known standard architecture known as the Model Driven Architecture. The Model-Driven Architecture (MDA) concepts from the Object Management Group (OMG) describe the idea that you can create a model of a system and generate code from the model. The commercial exploitation of MDA in the early prior art focuses on generating the code for a component from a model of its behaviour. This approach is often referred to as a Software factory. A good example description is available here: http://msdn.microsoft.com/architecture/overview/softwarefactories/
Some later prior art in this area involved using MDA modeling techniques to integrate a new COTS application into an existing IT infrastructure. See, for example, the Kabira Adapter Factory, and see also the Object Management Group's web pages describing the use of MDA to perform this integration. However, such prior art assumed that all of the requirements of the COTS application and IT infrastructure were known and fixed at the time when the integration process begins.
The prior art is therefore inflexible and does not take account of changing needs over time.
In addition to COTS applications, which usually need no customization, this problem also exists when integrating an existing software application that needs to be customized, into an existing IT infrastructure.